Prepare qcom-next based on tag 'Linux 7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#495
Open
sgaud-quic wants to merge 705 commits intoqualcomm-linux:qcom-next-stagingfrom
Conversation
…nect in Mahua SoC Document the RPMh Network-on-Chip (NoC) interconnect for the Qualcomm Mahua platform. Mahua is a derivative of the Glymur SoC. Many interconnect nodes are identical and continue to use Glymur fallback compatibles. Mahua introduces SoC-specific configurations and topologies for several NoC blocks, including CNOC, HSCNOC, PCIe West ANoC/Slave NoCs. This updates the existing Glymur yaml schema to include Mahua-specific compatible strings, using two-cell "fallback" compatibles wherever the hardware is identical with Glymur. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-mahua_icc-v2-1-f0d8ddf7afca@oss.qualcomm.com
Mahua is a derivative of the Glymur SoC. Extend the
Glymur driver to support Mahua by:
1. Adding new node definitions for interconnects that differ from Glymur
(Config NoC, High-Speed Coherent NoC, PCIe West ANOC/Slave NoC).
2. Reusing existing Glymur definitions for identical NoCs.
3. Overriding the channel and buswidth, with Mahua specific values for
the differing NoCs
Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260127-mahua_icc-v2-2-f0d8ddf7afca@oss.qualcomm.com
…operty to enable QoS Some QCS8300 interconnect nodes have QoS registers located inside a block whose interface is clock-gated. For those nodes, driver must enable the corresponding clock(s) before accessing the registers. Add the 'clocks' property so the driver can obtain and enable the required clock(s). Only interconnects that have clock‑gated QoS register interface use this property; it is not applicable to all interconnect nodes. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-2-odelu.kukatla@oss.qualcomm.com
Enable QoS configuration for master ports with predefined priority and urgency forwarding. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-3-odelu.kukatla@oss.qualcomm.com
Add clocks which need to be enabled for configuring QoS on qcs8300 SoC. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-4-odelu.kukatla@oss.qualcomm.com
Add cooling-cells property to the CPU nodes to support cpufreq cooling devices. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://patch.msgid.link/20260403-cpufreq-v1-1-9d465988c3f9@oss.qualcomm.com Signed-off-by: Aastha Pandey <aastha.pandey@oss.qualcomm.com>
Commit d4a44f0 ("iommu/arm-smmu: Invoke pm_runtime across the driver") enabled pm_runtime for the arm-smmu device. On systems where the SMMU sits in a power domain, all register accesses must be done while the device is runtime active to avoid unclocked register reads and potential NoC errors. So far, this has not been an issue for most SMMU clients because stall-on-fault is enabled by default. While a translation fault is being handled, the SMMU stalls further translations for that context bank, so the fault handler would not race with a powered-down SMMU. Adreno SMMU now disables stall-on-fault in the presence of fault storms to avoid saturating SMMU resources and hanging the GMU. With stall-on-fault disabled, the SMMU can generate faults while its power domain may no longer be enabled, which makes unclocked accesses to fault-status registers in the SMMU fault handlers possible. Guard the context and global fault handlers with pm_runtime_get_if_active() and pm_runtime_put_autosuspend() so that all SMMU fault register accesses are done with the SMMU powered. In case pm_runtime is not active we can safely ignore the fault as for pm runtime resume the smmu device is reset and fault registers are cleared. List: https://lore.kernel.org/all/20260313-smmu-rpm-v2-1-8c2236b402b0@oss.qualcomm.com/ Fixes: b130440 ("drm/msm: Temporarily disable stall-on-fault after a page fault") Co-developed-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com> Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com> Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
Devres APIs are intended for use in drivers, and they should be avoided in shared subsystem code which is being used by multiple drivers. Avoid using devres based allocations in the reboot-mode subsystem and manually free the resources. Replace devm_kzalloc with kzalloc and handle memory cleanup explicitly. Fixes: 4fcd504 ("power: reset: add reboot mode driver") Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-1-46e085bca4cc@oss.qualcomm.com
The reboot-mode driver does not have a strict requirement for device-based registration. It primarily uses the device's of_node to read mode-<cmd> properties. Remove the dependency on struct device and introduce support for firmware node (fwnode) based registration. This enables drivers that are not associated with a struct device to leverage the reboot-mode framework. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-2-46e085bca4cc@oss.qualcomm.com
Current reboot-mode supports a single 32-bit argument for any supported mode. Some reboot-mode based drivers may require passing two independent 32-bit arguments during a reboot sequence, for uses-cases, where a mode requires an additional argument. Such drivers may not be able to use the reboot-mode driver. For example, ARM PSCI vendor-specific resets, need two arguments for its operation – reset_type and cookie, to complete the reset operation. If a driver wants to implement this firmware-based reset, it cannot use reboot-mode framework. Introduce 64-bit magic values in reboot-mode driver to accommodate dual 32-bit arguments when specified via device tree. In cases, where no second argument is passed from device tree, keep the upper 32-bit of magic un-changed(0) to maintain backward compatibility. Update the current drivers using reboot-mode for a 64-bit magic value. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-3-46e085bca4cc@oss.qualcomm.com
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a read-only sysfs attribute exposing the list of supported reboot-mode arguments. This file is created by reboot-mode framework and provides a user-readable interface to query available reboot-mode arguments. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com
Currently, there is no standardized mechanism for userspace to discover which reboot-modes are supported on a given platform. This limitation forces tools and scripts to rely on hardcoded assumptions about the supported reboot-modes. Create a class 'reboot-mode' and a device under it to expose a sysfs interface to show the available reboot mode arguments to userspace. Use the driver_name field of the struct reboot_mode_driver to create the device. For device-based drivers, configure the device driver name as driver_name. This results in the creation of: /sys/class/reboot-mode/<driver>/reboot_modes This read-only sysfs file will exposes the list of supported reboot modes arguments provided by the driver, enabling userspace to query the list of arguments. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-5-46e085bca4cc@oss.qualcomm.com
SoC vendors have different types of resets which are controlled through various hardware registers. For instance, Qualcomm SoC may have a requirement that reboot with “bootloader” command should reboot the device to bootloader flashing mode and reboot with “edl” should reboot the device into Emergency flashing mode. Setting up such reboots on Qualcomm devices can be inconsistent across SoC platforms and may require setting different HW registers, where some of these registers may not be accessible to HLOS. These knobs evolve over product generations and require more drivers. PSCI spec defines, SYSTEM_RESET2, vendor-specific reset which can help align this requirement. Add support for PSCI SYSTEM_RESET2, vendor-specific resets and align the implementation to allow user-space initiated reboots to trigger these resets. Implement the PSCI vendor-specific resets by registering to the reboot-mode framework. As psci init is done at early kernel init, reboot-mode registration cannot be done at the time of psci init. This is because reboot-mode creates a “reboot-mode” class for exposing sysfs, which can fail at early kernel init. To overcome this, introduce a late_initcall to register PSCI vendor-specific resets as reboot modes. Implement a reboot-mode write function that sets reset_type and cookie values during the reboot notifier callback. Introduce a firmware-based call for SYSTEM_RESET2 vendor-specific reset in the psci_sys_reset path, using reset_type and cookie if supported by secure firmware. Register a panic notifier and clear vendor_reset valid status during panic. This is needed for any kernel panic that occurs post reboot_notifiers. By using the above implementation, userspace will be able to issue such resets using the reboot() system call with the "*arg" parameter as a string based command. The commands can be defined in PSCI device tree node under “reboot-mode” and are based on the reboot-mode based commands. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-7-46e085bca4cc@oss.qualcomm.com
…nd QMP Document PDC reg to configure pass through or secondary controller mode for GPIO IRQs. Document QMP handle for action concerning global resources. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-2-760c8593ce50@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
There are two modes PDC irqchip supports pass through mode and secondary controller mode. All PDC irqchip supports pass through mode in which both Direct SPIs and GPIO IRQs (as SPIs) are sent to GIC without latching at PDC. Newer PDCs (v3.0 onwards) also support additional secondary controller mode where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs still works same as pass through mode without latching at PDC even in secondary controller mode. All the SoCs so far default uses pass through mode with the exception of x1e. x1e PDC may be set to secondary controller mode for builds on CRD boards whereas it may be set to pass through mode for IoT-EVK. There is no way to read which current mode it is set to and make PDC work in respective mode as the read access is not opened up for non secure world. There is though write access opened up via SCM write API to set the mode. Configure PDC mode to pass through mode for all x1e based boards via SCM write. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-3-760c8593ce50@oss.qualcomm.com Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
…100 PDC Purwa shares the Hamoa (X1E80100) PDC device, but the hardware register bug addressed in commit e9a48ea ("irqchip/qcom-pdc: Workaround hardware register bug on X1E80100") is already fixed in Purwa silicon. Hamoa compatible forces the software workaround. Add PDC compatible for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa. Fixes: f08edb5 ("arm64: dts: qcom: Add X1P42100 SoC and CRD") Link: https://lore.kernel.org/r/20251231-purwa_pdc-v1-1-2b4979dd88ad@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Rename the hamoa camera DTBs variable to match the
hamoa-camera-camx DTB target naming and improve consistency
with existing Makefile conventions.
Fixes: 9041882f7c4c ("QCLINUX: arm64: dts: qcom: Add hamoa camx overlay
dts")
Signed-off-by: Ignatius Michael Jihan <mignatiu@qti.qualcomm.com>
…perty to enable QoS Aggre1-noc interconnect node on QCS615 has QoS registers located inside a block whose interface is clock-gated. Accessing these registers requires the corresponding clock(s) to be enabled. Update the bindings to include the 'clocks' property. Ensure that only aggre1-noc interconnect node uses this property by explicitly forbidding it for all other interconnect nodes. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311103548.1823044-2-odelu.kukatla@oss.qualcomm.com
Enable QoS configuration for master ports with predefined priority and urgency forwarding. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311103548.1823044-3-odelu.kukatla@oss.qualcomm.com
Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Link: https://lore.kernel.org/all/20260408-parse_iommu_cells-v13-1-fa921e92661b@oss.qualcomm.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Add an explicit filter_np parameter to of_map_id() and of_map_msi_id() to separate the filter input from the output. Previously, the target parameter served dual purpose: as an input filter (if non-NULL, only match entries targeting that node) and as an output (receiving the matched node with a reference held). Now filter_np is the explicit input filter and arg->np is the pure output. Previously, of_map_id() would call of_node_put() on the matched node when a filter was provided, making reference ownership inconsistent. Remove this internal of_node_put() call so that of_map_id() now always transfers ownership of the matched node reference to the caller via arg->np. Callers are now consistently responsible for releasing this reference with of_node_put(arg->np) when done. Link: https://lore.kernel.org/all/20260408-parse_iommu_cells-v13-2-fa921e92661b@oss.qualcomm.com/ Acked-by: Frank Li <Frank.Li@nxp.com> Suggested-by: Rob Herring (Arm) <robh@kernel.org> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use in being able to map at least single
input IDs to multi-cell output specifiers (and properly support 0-cell
outputs as well), add support for properly parsing and using the target
nodes' #cells values, albeit with the unfortunate complication of still
having to work around expectations of the old behaviour too.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Link: https://lore.kernel.org/all/20260408-parse_iommu_cells-v13-3-fa921e92661b@oss.qualcomm.com/
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Add the wrapped key support for sdhci-msm by implementing the needed methods in struct blk_crypto_ll_ops and setting the appropriate flag in blk_crypto_profile::key_types_supported. Tested on SC7280 eMMC variant. How to test: Use the "v1.3.0" tag from https://github.com/google/fscryptctl and build fscryptctl that supports generating wrapped keys. Enable the following config options: CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_QCOM_INLINE_CRYPTO_ENGINE=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_MMC_CRYPTO=y Enable "qcom_ice.use_wrapped_keys" via kernel command line. $ mkfs.ext4 -F -O encrypt,stable_inodes /dev/disk/by-partlabel/vm-data $ mount /dev/disk/by-partlabel/vm-data -o inlinecrypt /mnt $ fscryptctl generate_hw_wrapped_key /dev/disk/by-partlabel/vm-data > /mnt/key.longterm $ fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/vm-data < /mnt/key.longterm > /tmp/key.ephemeral $ KEYID=$(fscryptctl add_key --hw-wrapped-key < /tmp/key.ephemeral /mnt) $ rm -rf /mnt/dir $ mkdir /mnt/dir $ fscryptctl set_policy --iv-ino-lblk-32 "$KEYID" /mnt/dir $ dmesg > /mnt/dir/test.txt $ sync Reboot the board $ mount /dev/disk/by-partlabel/vm-data -o inlinecrypt /mnt $ ls /mnt/dir # File should be encrypted $ fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/vm-data < /mnt/key.longterm > /tmp/key.ephemeral $ KEYID=$(fscryptctl add_key --hw-wrapped-key < /tmp/key.ephemeral /mnt) $ fscryptctl set_policy --iv-ino-lblk-32 "$KEYID" /mnt/dir $ cat /mnt/dir/test.txt # File should now be decrypted Tested-by: Wenjia Zhang <wenjia.zhang@oss.qualcomm.com> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
… suspend resume Crypto reprogram all keys is called for each MMC runtime suspend/resume in current upstream design. If this is implemented as a non-interruptible call to TEE for security, the cpu core is blocked for execution while this call executes although the crypto engine already has the keys. For example, glitches in audio/video streaming applications have been observed due to this. Add the flag MMC_CAP2_CRYPTO_NO_REPROG as part of host->caps2 to control reprogramming keys to crypto engine for socs which dont require this feature. Link: https://lore.kernel.org/all/20260116121004.1829223-1-neeraj.soni@oss.qualcomm.com/ Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com> Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com> Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Starting with sc7280(kodiak), the ICE will have its own device-tree node. So add the qcom,ice property to reference it. To avoid double-modeling, when qcom,ice is present, disallow an embedded ICE register region in the SDHCI node. Older SoCs without ICE remain valid as no additional requirement is imposed. Co-developed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Co-developed-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260310113557.348502-2-neeraj.soni@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
…or SDHC Add an ICE node to kodiak SoC description and enable it by adding a phandle to the SDHC node. Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260310113557.348502-3-neeraj.soni@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
…or SDHC Add an ICE node to monaco SoC description and enable it by adding a phandle to the SDHC node. Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260310113557.348502-4-neeraj.soni@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
…MI2S1 TLMM pins This patch adds the Generic Pack Router (GPR) node together with Audio Process Manager (APM) and Proxy Resource Manager (PRM) audio service nodes to the Talos device tree description. It also introduces MI2S1 pinctrl states for data0, data1, sck, and ws lines, grouped into a single entry at the SoC-level DTSI for better reuse and clarity. Link: https://lore.kernel.org/all/20260409030156.155455-1-le.qi@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
…7212 codec Add the sound card node for QCS615 Talos EVK with DA7212 codec connected over the Primary MI2S interface. The configuration enables headphone playback and headset microphone capture, both of which have been tested to work. Link: https://lore.kernel.org/all/20260409030156.155455-1-le.qi@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
All the existing variants Talos boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, the remote processor firmware IOMMU streams are controlled by Gunyah. However, without Gunyah, the IOMMU is managed by the consumer of this DeviceTree. Therefore, describe the firmware streams for each remote processor. Add a EL2-specific DT overlay and apply it to Talos IOT variant devices to create -el2.dtb for each of them alongside "normal" dtb. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Link: https://lore.kernel.org/lkml/20260127-talos-el2-overlay-v2-3-b6a2266532c4@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Test Matrix
|
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
5ff8a42 to
159f17d
Compare
Test Matrix
|
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
159f17d to
5ff8a42
Compare
Test Matrix
|
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, define the necessary device tree nodes, including UART configuration and power supplies. The module provides a 3.3V supply originating from the main board's 12V rail. Add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node to represent this power hierarchy. Workaround: With the WCN6855 PMU node present, the driver unintentionally takes the pwrseq code path, which causes Bluetooth to fail to power up during an on -> off -> on transition. To unblock functionality, the PMU node is omitted and all Bluetooth power supply references point directly to vreg_wcn_3p3, keeping the driver on the non-pwrseq path. This is a temporary workaround. Once a proper M.2 binding/solution is upstreamed, both DTS and driver changes will be re-submitted aligned with the M.2 model. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Test Matrix
|
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
5ff8a42 to
740314b
Compare
Test Matrix
|
LAVA Failed Case Triage SummaryPR: #495 Job 80592 | SoC glymur-crdLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80592 Failed test cases in LAVA job 80592 (SoC: glymur-crd).
Job 80589 | SoC lemans-evkLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80589 Failed test cases in LAVA job 80589 (SoC: lemans-evk).
Job 80588 | SoC monaco-evkLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80588 Failed test cases in LAVA job 80588 (SoC: monaco-evk).
Job 80594 | SoC qcs615-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80594 Failed test cases in LAVA job 80594 (SoC: qcs615-ride).
Job 80591 | SoC qcs6490LAVA job: https://lava-oss.qualcomm.com/scheduler/job/80591 Failed test cases in LAVA job 80591 (SoC: qcs6490).
Job 80587 | SoC qcs8300-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80587 Failed test cases in LAVA job 80587 (SoC: qcs8300-ride).
Job 80595 | SoC qcs9100-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80595 Failed test cases in LAVA job 80595 (SoC: qcs9100-ride).
Job 80590 | SoC sm8750-mtpLAVA job: https://lava-oss.qualcomm.com/scheduler/job/80590 Failed test cases in LAVA job 80590 (SoC: sm8750-mtp).
|
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
740314b to
c02129c
Compare
Test Matrix
|
LAVA Failed Case Triage SummaryPR: #495 Job 81079 | SoC glymur-crdLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81079 Failed test cases in LAVA job 81079 (SoC: glymur-crd).
Job 81082 | SoC kaanapali-mtpLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81082 Failed test cases in LAVA job 81082 (SoC: kaanapali-mtp).
Job 81085 | SoC lemans-evkLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81085 Failed test cases in LAVA job 81085 (SoC: lemans-evk).
Job 81083 | SoC monaco-evkLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81083 Failed test cases in LAVA job 81083 (SoC: monaco-evk).
Job 81084 | SoC qcs615-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81084 Failed test cases in LAVA job 81084 (SoC: qcs615-ride).
Job 81086 | SoC qcs6490LAVA job: https://lava-oss.qualcomm.com/scheduler/job/81086 Failed test cases in LAVA job 81086 (SoC: qcs6490).
Job 81080 | SoC qcs8300-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81080 Failed test cases in LAVA job 81080 (SoC: qcs8300-ride).
Job 81078 | SoC qcs9100-rideLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81078 Failed test cases in LAVA job 81078 (SoC: qcs9100-ride).
Job 81081 | SoC sm8750-mtpLAVA job: https://lava-oss.qualcomm.com/scheduler/job/81081 Failed test cases in LAVA job 81081 (SoC: sm8750-mtp).
Job 81087 | SoC x1e80100LAVA job: https://lava-oss.qualcomm.com/scheduler/job/81087 No failed cases detected from the LAVA results section. |
This reverts commit 62a479d. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…truct" This reverts commit a4503c1. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This reverts commit e15bddf. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-1-fd02f11b6c38@oss.qualcomm.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Add an explicit filter_np parameter to of_map_id() and of_map_msi_id() to separate the filter input from the output. Previously, the target parameter served dual purpose: as an input filter (if non-NULL, only match entries targeting that node) and as an output (receiving the matched node with a reference held). Now filter_np is the explicit input filter and arg->np is the pure output. Previously, of_map_id() would call of_node_put() on the matched node when a filter was provided, making reference ownership inconsistent. Remove this internal of_node_put() call so that of_map_id() now always transfers ownership of the matched node reference to the caller via arg->np. Callers are now consistently responsible for releasing this reference with of_node_put(arg->np) when done. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-2-fd02f11b6c38@oss.qualcomm.com/ Acked-by: Frank Li <Frank.Li@nxp.com> Suggested-by: Rob Herring (Arm) <robh@kernel.org> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use in being able to map at least single
input IDs to multi-cell output specifiers (and properly support 0-cell
outputs as well), add support for properly parsing and using the target
nodes' #cells values, albeit with the unfortunate complication of still
having to work around expectations of the old behaviour too.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-3-fd02f11b6c38@oss.qualcomm.com/
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Bootup crash seen on kaanapali-mtp board. [ 8.114249][ C0] [drm:dpu_encoder_frame_done_timeout:2731] [dpu error]enc33 frame done timeout [ 8.116480][ T284] Unable to handle kernel paging request at virtual address ffff800080e5e000 [ 8.116488][ T284] Mem abort info: [ 8.116492][ T284] ESR = 0x0000000096000007 [ 8.116497][ T284] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.116502][ T284] SET = 0, FnV = 0 [ 8.116507][ T284] EA = 0, S1PTW = 0 [ 8.116511][ T284] FSC = 0x07: level 3 translation fault [ 8.116516][ T284] Data abort info: [ 8.116519][ T284] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 8.116524][ T284] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.116529][ T284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.116535][ T284] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000009bf36c000 [ 8.116541][ T284] [ffff800080e5e000] pgd=0000000000000000, p4d=1000000880346403, pud=1000000880347403, pmd=1000000881e2d403, pte=0000000000000000 [ 8.116567][ T284] Internal error: Oops: 0000000096000007 [#1] SMP Revert the change for now to unblock. This reverts commit f66a882. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
c02129c to
6771649
Compare
Test Matrix
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Name SHA Commits
tech/bsp/clk 0f5a318 14
tech/bsp/interconnect ec1ab95 7
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra c793ce5 5
tech/bsp/pinctrl 28c2b80 1
tech/bsp/remoteproc abb91ae 5
tech/bus/peripherals 0849a10 6
tech/bus/pci/all 6a697f8 6
tech/bus/pci/mhi fb9c163 1
tech/bus/pci/phy aaf8ef1 4
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy 8c7f91d 35
tech/debug/hwtracing 87ae82d 31
tech/pmic/misc e6525e3 9
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu e31b170 5
tech/mm/audio/all 06f5706 16
tech/mm/camss 7c584e4 29
tech/mm/drm fa2d11c 15
tech/mm/fastrpc c29b2a8 5
tech/mm/video 72e188f 29
tech/mm/gpu 9c8e55d 2
tech/net/ath 0fa4871 3
tech/net/eth 49b156f 1
tech/net/qrtr 64d75f7 1
tech/net/phy a3602e9 1
tech/net/bluetooth 229e73e 3
tech/pm/power 2c0fae8 10
tech/pm/thermal d174ed3 6
tech/security/crypto a6ce790 12
tech/security/ice 7a9d8eb 26
tech/storage/phy cf1667f 1
tech/storage/all e254dae 1
tech/all/dt/qcs6490 5df38ca 19
tech/all/dt/qcs9100 c98cdc0 22
tech/all/dt/qcs8300 a32d843 27
tech/all/dt/qcs615 cdbdac6 27
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa 0c8d1c1 38
tech/all/dt/glymur ac7a496 32
tech/all/dt/kaanapali 710775e 28
tech/all/dt/pakala f6b63a0 7
tech/all/config b31ed76 57
tech/overlay/dt 2d3b16a 34
tech/all/workaround c3f9d3b 13
tech/mproc/all b204da4 5
tech/noup/debug/all a8695a4 19
tech/hwe/unoq ce06e26 16